分类
    联系方式
    1. 新浪微博
    2. E-mail

    Maeiee Weekly No.6

    文章

    1. 《Emacs as a Time Tracker》
      1. 时间跟踪帮助更好管理自我、更好利用时间
      2. 尝试过的工具
        1. 电子表格：能用，但是不完美
        2. GTK timetaker：不错，但是不跨平台
        3. Markdown：输入简单，统计费劲
      3. 看 YouTube 视频学 Emacs/Org Mode
        1. 注：教程确实很多
      4. Org clock workflow
        1. 每天开始，建新 org 文件，创建任务清单
        2. 开始任务，org-clock-in，doom emacs spc m c i
          1. org-clock-out，doom emacs spc m c o
        3. click in（打卡），任务添加新计时条目
        4. org 顶部创建表格，时间报告 org-clock-report，spc m c R
        5. 更新时间报告 org-update-all-dblock
      5. 不建议非 Emacs 使用，学成本太高
    2. 《Application binary interface - 维基百科》
      1. ABI 是二进制程序模块之间的接口，包括：
        1. 处理器指令集，寄存器结构、堆栈组织、内存访问类型
        2. 数据库可直接访问的基本数据类型和布局
        3. 调用约定，传参、返回值方式
        4. 如何进行系统调用
        5. 对象文件、程序库的二进制格式
      2. 一头是库或者操作系统特性，另一头是用户程序
      3. 定义了如何在机器码中访问数据结构或程序
        1. 低级的，依赖硬件的格式
        2. 举例 X86 调用约定（x86 calling conventions）
      4. 遵守 ABI 是编译器、操作系统、库的任务
      5. 英特尔二进制兼容标准（iBCS）
        1. 允许支持该 ABI 的操作系统的程序
        2. 无需修改在这一类系统上运行
    3. 《[Dart翻译]用Dart和Wasm做实验》
      1. Wasm GC 提案
        1. 最初 wasm 不是为 GC 语言（Dart、Java/Kotlin）而设计
        2. GC 语言编译到 wasm 困难
      2. 将 Dart 编译到 wasm
        1. 早期探索阶段，感兴趣
        2. wasm 缺乏 GC，Dart 必须将垃圾回收实现一同编译
          1. GC 实现过于复杂
          2. 增加包大小、启动耗时
        3. dart2wasm 原型：效果不错
      3. Dart 与 wasm 互操作性（interop）
        1. Dart 中加载并调用 wasm 模块
        2. Dart FFI：与 C 库相互，缺点是特定于平台，分发复杂
        3. 分发 wasm 模块简单，一份二进制到处执行，通过 pub 分发
        4. package:wasm：
          1. 基于 wasmer，支持 WASI 操作系统交互接口
          2. 加载 wasm 二进制，Dart 对象 WasmModule
          3. .describe() 描述模块内方法，.instantiate() 构建实例
          4. 查看模块实例占用的内存
        5. 案例1：Brotli 压缩库
          1. Brotli 编译为 wasm 模块
          2. 在 Dart 中载入 Brotli
          3. 传入文件，进行压缩、报告压缩率、解压
        6. 将 C 语言编译为 wasm：通过 wasienv
    4. 《标准化中的 WASI：在 web 之外运行 WebAssembly 的系统接口》
      1. WebAssembly System Interface，wasm 系统接口
      2. wasm 需要概念操作系统的系统接口
      3. 三份实现：
        1. wasmtime，Mozilla 的 WebAssembly 运行时
        2. Lucet，Fastly 的 WebAssembly 运行时
        3. 浏览器 polyfill
      4. 什么是系统接口？
        1. 保护屏障：内核
        2. 系统调用：内核向用户空间提供的接口
      5. Emscripten
        1. 在 Web 上模拟 POSIX
        2. Emscripten 定制 libc（wasm + JavaScript 胶水）
      6. 可移植性
        1. POSIX、Unix：源码可移植性，一次编写多次编译，到处执行
        2. wasm：一次编写，一次编译，到处执行
      7. wasi-core
        1. 类似 POSIX，所有程序需要的基本接口
        2. 文件、网络、时钟、随机数……
        3. wasi-sysroot：根据 wasi-core 实现 libc
    5. 《WebAssembly Aims to Eliminate the File System》
      1. WASI 最新计划取消文件系统，甚至也包括操作系统
        1. WebAssembly System Interface
        2. WASI 字节码联盟联合创始人 Lin Clark 声明
      2. WASI
        1. 将 WebAssembly 移出浏览器
        2. 贴近处理器 ISA 架构提供底层抽象
        3. WASI 提供一套围绕操作系统的 "狭义范围 " API
        4. 模块化结构，可扩展
      3. 文件系统：“文件”存储数据集，一个隐喻，数据在各程序间共享
      4. WASI 虚拟文件系统（老架构）
        1. 文件本身位于 WASM 模块中
        2. I/O类型，如流和数组，具有完全的可移植性
      5. WASI I/O （新架构）
        1. 程序不会调用文件，而是调用 I/O类型本身的指针
        2. 数组、字符串
        3. 开发者不再考虑文件问题，只考虑纯粹的 I/O 操作
      6. 新架构的好处
        1. 简化同一 Pod 上两个容器的通信
        2. 省去序列化和反序列化，省去 I/O 多次拷贝
      7. WebAssembly为Kubernetes提供安全保障
        1. Krustlet：运行 wasm workload
        2. KubeWarden：k8s 策略引擎和 admission 控制器
          1. k8s 最佳实践策略即代码
          2. 要么编写大量 YAML 文件，要么学习一种新语言
          3. 通过 KubeWarden 使用 Rust 或 Golang 编写策略
    6. 《Why WebAssembly Belongs Outside the Browser》
      1. 为什么 WebAssembly 属于浏览器之外
      2. Wasm 历史
        1. 2015 Luke Wagner 声明
        2. 两个主要目标：
          1. 在浏览器中运行二进制的标准
          2. 推动各大浏览器支持
        3. WebAssembly Core Specification
        4. 大规模落地：Adobe、Figma
      3. 非浏览器运行时
        1. Wasmtime、Wamr、Wasm3、WasmEdge、Wasmer
        2. WebAssembly System Interface (WASI)
          1. 访问系统资源：文件系统、环境变量、时钟、随机数
        3. Bytecode Alliance：字节码联盟
      4. 用于运计算的优势
        1. 安全：隔离状态运行不受信任的代码
        2. 跨平台/跨架构：编写一次，到处运行
        3. 多语言（Polyglot）：
          1. WebAssembly 一大目标将浏览器扩展到多语言
          2. 云开发更加需要多语言
        4. 高性能、执行效率、二进制大小
      5. 安全
        1. wasm 提供一个简单的、容易理解的表面区域
        2. 确保代码在沙盒内运行
        3. 沙盒边界互动被明确定义
        4. 在简单性和可攻击面低于虚拟机和容器
      6. 跨平台/跨架构
        1. 完全与平台和架构无关的
        2. 远远超过诸如 JVM 或其他 "一次编译，随处运行 "的技术的想象
        3. 真正实现一次编译，在任何地方运行
        4. 其中真正的亮点在于组件模型
          1. 开发者编写代码，并将他们的API作为接口输出
          2. 可以使用任何语言实现
          3. 接口实现方和使用方使用不同语言
        5. 作为 Kubernetes 运行时
          1. 容器的缺点：在任何地方运行的背后
            1. 为了支持不同的平台，平台+arch组合建立不同镜像
            2. 容器是一种 Linux 技术
            3. 容器开销导致无法接近边缘
          2. 在云服务器和边缘设备可以执行同样的代码，不需要重新编译
      7. Polyglot 多语言
        1. 许多语言开始支持 Wasm 编译
        2. 同一个程序不同部分，用不同语言来编写
        3. Wasm 有望成为终极插件模型
      8. 速度
        1. 边缘计算、物联网：虚拟机和容器妨碍从硬件中获取性能
        2. 我们可以（而且应该！）直接在裸机上运行 Wasm
      9. 高性能、执行效率、二进制大小
        1. 降低伸缩成本
        2. JIT/AOT 运行时：性能更高
    7. 《Easing into Emacs org-mode》
      1. 提高生产力不是一件容易的事
      2. 长久使用 TaskPaper
        1. 经营数百万美元业务和个人生活
        2. 局限性：日期、二次开发、重复任务、macOS 单平台
      3. 扩展：
        1. deft：快速创建、搜索、添加笔记
          1. 受到 Notational Velocity 的启发
            1. fork：nvALT
          2. 派生出 Zettledeft：Zettelkasten 信息系统
        2. org-mode 扩展：
          1. org-journal：记日记
          2. org-habits：习惯跟踪
            1. 可视化展示
            2. 避免在长期目标上自欺欺人
          3. org-super-agenda：议程
            1. 对议程日历的增强
            2. 分类：今天、习惯、即将到期、已到期
            3. 强烈推荐，定制性高
      4. Workflow 以周维度管理
        1. 标签形式 w35，代表第35周
        2. 标签分类：上下文维度、工作类型
        3. 组合标签：:ea:perso:w26: 指派给行政助理的私人事务
        4. 5 个 TODO 状态划分：TODO、WAIT、GAVE (委托)、KILL (取消)、DONE
        5. Deft+org-journal+org-caputure：快速放入收件箱，以便日后处理
        6. 创建每日日记
        7. 每日工作流
          1. 调出每日视图
          2. 处理收件箱：移到它们应该在的地方
          3. 看一下到期、逾期和即将到期的事情
          4. 处理待办事项视图
      5. 没有使用计时功能：
        1. 这是疯狂的矫枉过正
        2. 我是在努力提高工作效率
        3. 而不是为我一天中的每一分钟辩解
        4. 尽管有可能帮助找出浪费的时间
      6.  :LOGBOOK: 跟踪
        1. 直到在什么时候做了什么
        2. 对实际花费的时间有了更多认识
      7. Contacts 模块：生日、纪念日支持，日程融合
      8. 缺点：
        1. 你想改变 org mode，实际上是 org mode 改变了你
        2. 定制门槛高，被 elisp 的奇怪咒语洗脑了
        3. 围绕 emacs 痴迷
        4. 痴迷折腾配置，结果该干的活没干
      9. 末尾包含一份 Org Mode config
    8. 《Going from JavaScript to WebAssembly in three steps》
      1. Micrio：在线看超高清油画的平台
        1. 从 JavaScript 实现迁移到 WebAssembly
      2. 考虑因素：性能、流量、浏览器兼容性、体验
      3. WebAssembly (Wasm) 介绍
        1. 在浏览器中以接近原生速度运行编译后代码
        2. W3C 标准认证
        3. 第 4 官方 Web 语言（继 HTML/CSS/JavaScript）
        4. 支持语言：
          1. C/C++、Rust、Go、AssemblyScript 等
          2. 在浏览器中运行
      4. JavaScript 版本
        1. 使用 Canvas2D 渲染 2D 图像
        2. 使用 three.js/WebGL 渲染 360° 图像
        3. 使用 ES6 JavaScript 编写
      5. wasm 尝试1：C++、emscripten
        1. emscripten：
          1. 将 C/C++ 项目编译为 .wasm 二进制
          2. 在浏览器中原生执行
        2. emscripten 对 libsdl 良好兼容性
          1. 底层音频、键鼠外设、OpenGL
        3. 最大的挑战是捡起 C++ 语言
        4. 效果：运行流畅
      6. 不足
        1. 老套的 C++
          1. 像回到了过去
          2. 对 Web 开发者有些过时
          3. 花了很长时间优化 Makefile
        2. 编译后的 .wasm 很大
          1. WebAssembly binary 760KB
          2. 对比 JavaScript 版本 240KB
          3. 二进制里打包了很多 Micrio 没用到的功能
        3. 胶水文件 glue
          1. wasm 需要对 JavaScript与浏览器绑定
          2. 浏览器不会自动识别 C++ 代码
          3. emscripten 插入额外胶水 JavaScript
          4. 加上胶水，总包大小 791KB，太大了
      7. wasm 尝试2：AssemblyScript
        1. AssemblyScript
          1. 专门为 WebAssembly 创建的语言，使用 TypeScript 语法
          2. 写（近似）TypeScript，编译成 wasm 二进制
          3. 基于 npm 生态，前端友好
          4. 提供 glue-tooling
          5. JavaScript 以同步调用 AssemblyScript 导出模块
        2. 架构改进思考
          1. 部分下沉到 WebAssembly
          2. 之重写坐标计算部分，渲染、时间处理仍 JavaScript
        3. 结果
          1. 包大小 3KB
          2. 将 wasm 通过 base64 写入 JavaScript Bundle
      8. wasm 尝试3：完全用 AssemblyScript 重写
        1. WebAssembly 内存 WebGL 打通
          1. WebAssembly 程序允许申请 16MB 内存
          2. 该内存在 JavaScript 可访问（像访问 ArrayBuffer）
          3. WebAssembly 将 3D 数据放入内存，JavaScript 将其传入 WebGL
      9. 效果测试
        1. 三个版本：JS/Wasm/Wasm+WebGL
        2. 包大小：JavaScript（444KB）+ three.js（607KB），尝试3（371KB）
          1. 服务器 gzip 压缩后，实际 73KB
        3. CPU：65% less CPU